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(54) Software rental system and method for renting software 

(57) A software rental system is provided compris- 
ing at least one rented program permitting at least one 
service to a customer with a customer's reponse 
means, wherein 



said rented program has no access to a customer's 
private keying material, 

using asymmetric cryptography, said customer's 

reponse means proves to the rented program, that 

said customer's reponse means has access to the 

customer's private keying material, and 

said rented program does not permit said at least 

one service to said customer unless the proof is 

successful. 
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Description 



[0001] With few exceptKsns. rrxjst computer programs are instantiations of intellectual property and execute upon 
demand after installation h4ormaliy. one can build and install an inexpensive copy of a computer program by little more 
than simply executing a copy command. A physical asset such as an automobile, on the other hand, cannot be easily 
copied As a result, it is much easier to provide rental of physical assets than rental of computer programs. In the case 
of a physical asset the renter first pays a rental fee. and then physically takes possession of the asset. At the conclusion 
of the rental period, the renter returns the physical asset to the owner. In the case of software, on the other hand, it 
makes little sense for the customer to return the program to the owner because one cannot guarantee that the customer 
refrained from sequestering h.s or her own backup copy. In the absence of adequate security measures, a customer 
acting in the role of an attaci^e. could potentially rent the software for a short period of time and subsequently use the 
sequestered backup without paying further rental fees. 

[0002] In this invention we define software rental as a computer system and method that securely stores rental 
(usage) records. For exarrple. consider the time-of-use rental metric. If the customer, executes the rented software for 
one hour on the first day and two hours on the second, then the secured audit trails show one hour at the end of the first 
day and three houre at the erx3 of the second day. Secure software rental implies that a customer cannot defeat system 
security by purging, replaoog or moditying audit trails. Normally, the software continually monitors the audit trails to 
determine when a threshoW * exceeded. So. if the example software has a five hour threshold, then the customer m^ 
execute the software for two more hours and then the software slops. Another example threshold is the total amount of 

times that the software may execute. 

[0003] Some rental mechan^ms that have all the properties listed above of our invention currently exist, e.g., Dongies 
[1] Dongies have non-volatile memory which may be protected by passwords. This password protected memory may 
potentially used for software lental. A characteristic of this rental mechanism is that it requires the assistance of a 
secured rental device e g . a Dongle. The secured rental device contains Secured Updateable Storage Locations 
(SUSLs) that record information reteted to usage of the rented software. Each SUSL has the property that the SUSL 
r^dss on a secured device and prowdes protection against ateck. Nonnally, at least one SUSL for eachunit of rsnte^ 
software is required. For exaitple. if a customer rents a word processor, a spread sheet, and a game, then the rental 
device(s) must provide at least three SUSLs. These SUSLs are relatively expensive and difficult to administer, when 
compared with other storage on the customer's machine, e.g.. memory or disk space. 

[0004] Software rental, furtherrrxxe. significantly differs from a subscription to a network service. For example, sup- 
pose a software vendor provides a server to which customers conned via their software clients. Dunng the penod of 
the connection, the server audits usage records, e g., connect time. The vendor assesses charges based upon the 
information recorded in the server s audit trail. This client-server example differs from this present invention because we 
do not necessarily require an on-line presence by the software vendor. Rather, after obtaining permission to use the 
rented software, the customer executes the software without any required network connections. Furthermore, the sub- 
scription service does not prevent the customer from caching frequently used items. 

[0005] An overview on asymmetric cryptography, for example on the RSA scheme, and probabilistic encryption, for 
example the Blum-Goldwasser probabilistic public-key encryption scheme can be found in [2]. 
[0006] An oven^iew over different probabilistic proof schemes, for example zero knowledge proof schemes (e.g. 
Feige-Fiat-Shamir scheme. Gullou-Qulsquater scheme, Blum-Feldmann-Micali scheme. Brassard scheme. Crepau 
scheme, etc.) or witness hiding proof schemes (e.g. Feige-Shamir scheme, etc.) can be found in [2]. 
[0007] An overview of digital signature schemes (e.g. Rivest-Shamir-Adleman. etc..) and a formal mathematical def- 
inition of digital signatures can be hwnd in [2]. X- 
[0008] An example of a message digest function (otherwise known as a one-way hash function) is MD5 [3]. It is com- 
fs putationally infeasible or very difficUt to compute the inverse of a message digest 

[0009] In [4], cryptographic randomness from air turtxilence in disk drives is described. 
[001 0] The Chi-Square Test, the Kolmogorov-Smirnov Test, and the Serial Con-elation Te^ are described in [5]. 
[001 1] An asymmetric cryptographic mechanism includes public k^ng material and con-esponding pnvate keying 
material It is computationally infeasible to compute the private keying material when given no more infomiation than 
-,o the corresponding pdbWc keying material. In this invention, we use asymmetric cryptography in interactions between fcwo 
parties. A and B. A proves to B that A has access to private keying material and B vafidates the proof. A does not dis- 
close the private keying material to B. 

Digital signature scheme 

[001 2] A digital signature is an electronic analog of a handwritten signatura A digital signature proof involves at least 
two parties. A and B. After posting his or her public keying material to a public location, A encrypts a message using the 
private keying material. Since anyone may access the public keying material, there is no message secrecy. Howa/er. 
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since A is the only custonner with access to the private keying material, no one else can "forge A's signature" by per- 
forming the encryption. Anyone may validate A's signature using the public keying material - simply decrypt using A's 
public keying material. 

[001 3] An asymmetric confidentiality proof involves at least two parties. A and B. A possesses private keying material 
5 and B has no access to A's private keying material unless B discloses the private keying material itself (which B should 
not do). At the beginning. A and B have no shared secret. During the method, a shared secret becomes known to A and 
B. 

[0014] In all asymmetric cryptographic schemes, each customer may post his or her public keying material to a pub- 
licly accessed directory without compromising the corresponding private keying material. The customer usually should 

10 guard his or her private keying material as a close secret; otherwise, the cryptographic systenn may not guarantee cor- 
rectness (secrecy). The best known mechanism for protecting one's private keying material is through the use of a 
smart card. In this case, the smart card is a device with no interface for releasing private keying material (in a non-cryp- 
tographically protected form). All cryptographic operations that directly reference the private keying material are per- 
formed on the smart card itself. As a result, no one can discover the contents of the private keying material stored on a 

15 smart card. 

[001 5] Although smart cards provide the best protection, social factors of electronic commerce may provide a role in 
ensuring private keying material protection. One of the significant difficulties associated with asymmetric encryption 
services is authentcation. For example, if A posts his or her public keying material to a public directory, then how does 
B assess validity That is. a pirate may attempt to masquerade as A but post the pirate's teying material. Some com- 
20 mercial organizations provide solutions to this problem by acting as Certification Autiiorities (CA). For (px>ssibly) a fee. 
the CA Goiicits identifying material from potential customers such as a driver's license or passport. After validating the 
identrfyir>g material, the CA posts the customer's public keying material to a public directory, and the CA signs a certif- 
icate (using a digital signature with the CA's private key) that holds the customer's public keying material. Standardized 
services, tor example X 500. may be adopted to help facilitate the use of directories that contain public keying material- 
's [001 6] Once a customer posts his or her public keying material to the CA, the customer will protiably make an exten- 
sive effort to protect his or her private keying material. For some asymmetric keys, if the customer's private keying mate- 
rial were to become unknowingly compromised, then the customer would have cause for significant concern. For 
example, m the case of RSA keys that can also be used for digital signatures, networked vendors could potentially 
authorize electronic comn>erce transactions. 
30 [0017] The object of the present invention is to create a cryptographically secure software rental system. 

Summary of the Inventton 

[0018] According to the nvention tiiere is provided a software rental system comprising at least one rented program 
35 permitting at least one service to a customer with a ctetomer's response means, wherein 

said rented pro-am has no access to a customer's private keying material, 

using asymmetric cryptography, said customer's response means proves to the rented program, that said cus- 
tomer's response means has access to the customer's private keying material, and 
40 - said rented program does not permit said at least one service to said customer unless the proof is successful. 

[0019] According to a further aspect of the invention there is provided a software rental system connprising at least 
one rented program arxj private keying material such that the software rental system securely stores audit trails, 
wherein the correctness of said audit trails is validated using asymmetric cryptography. 
45 [0020] According to a further aspect of the invention there is provided a method of distributing a program to a plurality 
of customers wherein each customer has a software rental system as described above, and wherein every customer 
receives an identical copy of said program. 

[0021] According to a further aspect of the invention there is provided a method for renting software comprising at 
least one rented program permitting at least one service to a customer with a customer's reponse means, wherein 

50 

said rented program has no access to a customer's private keying material. 

using asymmetric cryptography, said astomer's reponse means proves to the rented program, that said cus- 
tomer's reponse means has access to the customer's private keying nnaterial. and 

said rented program does not permit said at least one service to said customer unless the proof is successful. 

55 

[(K)22] According to a further aspect of the invention tiiere is provided a metiiod for renting software comprising at 
least one rented program and private keying material such that tiie software rental system securely stores audit t^ils, 
wherein tiie correctness of said audit trails is validated using asymmetric cryptography. 
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[0023] We provide a new mechanism in which the number of required SUSLs is not a function °* ""1^'^^^:^':^^^ 
orSrimTln carticular this invention requires only a single SUSL regardless of the number of rented programs or 
SeTor nof thie p oTrLs simuitanSusly execute. For example, a customer could P-^t^-^'^'-y^'^^f ^^^'^^^^^^^ 
:JtMOO or more rent'ed programs while using only a single SUSL The SUS^eq-es no ^^^^ 
to protect an unlimited number of rented programs. In some cases a single 32-brt ^USL or a angle 64-brt SU^^^ 
be sufficient As we will describe later, we use the SUSL to denote a single non-negative integer. We use th'S .nteger 
ll J cc^Sth^t begins at an initial value (normally zero) and ends at the highest value that can be represented by ttie 
SunrSndS^orma. circumstances, is not possble to count through all of the possible ""^^^^^ J"^^^^^^^^^^ 
sent2 by a 1 28-bit counter. Even if one were to build a machine that could increment the counter friH^ons .l""es each 
;Sofd^one SulS normally want to count this fast), then it would take millions of years to reach the maximum value 

!'o024rThte ir!^ention tiso provides a new method for distributing rented software. In this method, a customer iroy rent 
nTipilSions f!om any vendor whenever he or she wishes. The customer does not need to install new external 

bBckuD and restore attack as described below. Suppose that a rented application requires no SUSL An atlacke may 
Ss^liTby peSming the following steps. First, the attacker in the role of an authorized rental ="=^^^^9^ 
m Jl rS^ a program. Nei. the attacker builds a full system backup of all of the non-volatile memory on «f ^ 
mSfne tit the attacker executes the rented program. Next, the attacker shuts down and rebo°te his or her 
mach ne FiSly. the attacker restores the state of the non-volatile memory to the original state ^*JJ^«"^ °< 
bacC At this point, the attacker has destroyed any possible record that the program vj«s previously rerted^ An SUSL 



Sr^;Sfan^;^;Se^K5^^^^ 
°h?s kS copy JtiNe toy. Therefore, at the conclusion of the rental period the customer can no longer use the soft- 
ware because the customer will no longer be able to provide an appropriate key. 
10027] In a further aspect of the invention there are multiple rented programs, wherein 

- said rented programs access the same public keying material , and 

- customer's private keying material is stored on a smart card. 

[0028] To further improve the security it may be advantageous that 

- at least one usage parameter of said at least one program is stored in an audit trail, and 

- rerJi pSam does not permit said at least one service to sad customer unless said at least one usage 
parameter is within a predetermined threshold. 

[0029] in a further aspect of the invention said at least one usage parameter is a rental time period for renting said at 

'lS"'in ?S"her aspect of the invention sad at least one usage parameter is an amount of usage of said at least 
one program. 

[0031] To further impro\^e the security it may be advantageous that 

«;aid at least one usaqe parameter is checked multiple times, and ... 
. re^ pro^S^ doZ not pem^it said at least one service to said customer unless said at least one usage 

parameter is in a predetermined interval each time it is checked. 

[0032] To further improve the security it may be advantageous that there is provided a rental server that syn:*|[°"«^ 
aS to a smart ca«l on which a customer's private keying material is stored and/or to an audrt trail 'nwhi* usage 
pSa^eler^ Sd^ least one program is stored. Thus, there is a central instance which responsible for much of the 

software rental (but not necessarily security). ^ , ^^ia o. .wit trail 

SoS^ m a further aspect of the invention said program stores said at least one usage parameter in sad audit trail. 
[00341 In a further aspect of the invention, aspects of said audit trail are stored securel)^ 

OOsS in a further aspect of the invention, portions of said audit trail are stored on an rnedium that >s nrt secure. Th« 
maS the system easier and less expensive to be realized without sacrificing security. However, aspects of said audit 
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trail are stored in an SUSL (the SUSL stores a single counter value). 

[0036] To further improve the security it may be advantageous that the smart card performs ah atomic routine that 
both executes a digital signature and an operation computed over an SUSL of said smart card, where the value held in 
the storage location changes over time. 
£ [0037] To further Improve the security it may be advantageous that the system Includes a keyfile for holding public 
keying material. 

[0038] To further improve the security it may be advantageous that said public keying material held In said keyfile is 
cryptographically secured, whereby it is computationally not feasible to alter any portion of the keyfile, including the first 
public keying material, without altering the challenge means (defined later). 
10 [0039] To furtiier improve the security it may be advantageous that keyfile includes information identifying said cus- 
tomer said program has been supplied. 

[0040] To further Improve the security it may be advantageous that said keyfile includes decoy bits for disguising the 
said public keying material held therein. 

[0041 ] To further improve flexibility, it may be possible to use software rental without defining a threshold, in this case, 
15 the software may be rented without limit However, the customer is trusted to periodically send his or her audit trails to 
the vendor and submit associated payment. 

Brief Description of the Drawings 

20 [0042] 

Figure 1 is a block diagram showing the architecture of the software rental system. 

Rgure 2 is a block diagram showing the software components that are required to be installed in the customer's 
25 machine. 

Figure 3 is a flowchart showing the operation of a random number generator used to generate nonces. 
Figure 4 is a block diagram showing a rental software purchase scenario. 

30 

Figure 5 is a block diagram showing the smart card architecture. 

Figure 6 is a block diagram showing an example audit trail. 

35 Description of an Embodiment of the Invention 

[0043] One embodiment in accordance with the invention will now be described by way of example with reference to 
the accompanying drawings. 

[0044] Rgure 1 illustrates the system's 100 architecture. Potentially multiple applications (programs) of software 
40 reside on the system where each application has its own keyfile, which Is explained in detail later. Rgure 1 illustrates 
three applications, a Word Processor 104. a Spread Sheet 105, and anotha- application 106 which access keyfBes 101 , 
102, arxl 103, respectively In some cases multiple applications 104, 105, 106 may share a common keyfile. 
[0045] Each of the applications 104, 105. 106 accesses its keyfile 101 . 102, and 103 to extract the customer's public 
keying material as described later in detail. 
45 [0046] Each application vendor inserts rental instructions into a copy protected program These rental instructions 
create log records, e.g., 109. 110. 111. For example, every fifteen minutes that Word Processor 104 executes. Word 
Processor 104 creates the following log record: „Word Process WP with public key 
9828a8c12a5873654bac684517d3afe3 executed for 15 minutes" (note that the record could store the message digest 
of the public keying material rather than the public keying material itself). Next the application sends its log record to a 
50 Rental Server 1 07. The Rental Server 107 inserts the log record at the end of a secure audit trail 1 08 stored at a poten- 
tially unsecured storage location, e.g., a file on a disk. The Rental Server 107 relies on the assistance of a Smart Card 
112 for security. 

[0047] An application, e.g.. 104, 105,. or 1 06, may choose to create a log record that contains any arbitrary string of 
bits with arbitrary length. In addition, or in lieu of recording time, an application could potentially log the number of times 
55 that the application or some of its modules executes. For example. SS 105 could potentially append a single log record 
each time SS boots: ..Application SS with public key 768230aac8239d9df88cfe3c7b832a is executing". Different types 
of audit records, e.g., time of usage or number of times that usage occun-ed may appear in the same audit trail. Multiple 
rented applications may simultaneously use the same audit trail. 
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r00481 One obtains software rental by matching thresholds against the audit trail. Rgure 4 illustrates a customer 402 
who rents software from a vendor 401 . First, the customer 402 sends a request to rent the software to the vendor 401 
in an order request 403. In this example, the customer purchases six hours of application 104. After recemng paymert^ 
he^endor sSds to the customer a keyf ile 404 that contains a usage authorization. In this case, the keyf .le 404 permrts 
six hours of execution by application 1 04. Tine later described keyf ile 404 may potentially contain other informaton, e.g.. 
copy protection or licensing information. 

[0049] Periodically, the rented application, e.g.. word processor (application) 104. examines the audrt traH 108- If ttie 
audrt iail 108 is not valid, then word processor 104 does not pemiit itself to be rented. However, rf the audrt tra.1 108 .s 
vaS hen the application 104 analyzes the audit tral and compares the analysis against the keyfile 404. For example^ 
aopli'cation 104 counts the number of log records that describe 15 minute intervals. Next, application 104 looks into the 
Sii?4^ to locate a rental threshold which in this present example is 6 hours (24 x 1 5 minute intervals). If aPPLcaton 
I04locatesfewerthan24of itslog records denoting 15 minute intervals, then application 104 continues executng^ ^h- 
enwise application 104 does not permit itself to be rented. In the latter case, the customer must purchase a new keyfHe 
TnTrder^corrtnue renting application 104. If application 104 were to exceed its rental threshoW. then o^^rter apphcj 
tions eg spread sheet 1 05 and other application 1 06 woukJ not be effected. That is. each rented applicaton views rts 
own records from the audit trail without interpreting records created by other applicatons. 

moSOl From the ciscussion above, we can see that the architecture implements software rental provided that the 
rented applicatkjns. e.g.. 104. 105. 106. can unequivocally validate the audit trail 108. The following properties should 
be satisfied 

1 Holes A rented application, e.g. word processor 104. in this present example validates that the audit trail con- 
tains all of the records that have ever been written regardless of application. If an application has previously wrrtten 
ten too records then the rented application, e.g.. word processor 1 04. wouW not validate the audrt trail if the rented 
appl«ition axjfeJ not locate all ten log records. We require an absence of holes, because we do not wish to permit 
25 an attacter to delete individual log records in order to destroy a record of usage. 

T7.Z^~r^ — 'ication sg word processor 104. n^st unequivocally conclude that no unauthorized 
ts^'^ilea'^ of vyff>"riog°r^l^"othTr^^. for sample, the attacker could modify all of the 15 minute 
log records to 1 5 second log records in order to dramatically increase the amount of time that the software may exe- 

SOjaem A rented application, must be able to validate that the audit trail 108 is current. Othenwise. the audrt trail 
1 08 could potent«lly be oU. thus hiding relatively new audrt records 109. 1 10. 1 1 1 . One would not wish, for exam- 
ple, an attacker to perfcxm the backup and restore attack. 

roosil These three properties remove all incentive for an attacker to corrupt, delete, lose, or othenwise abuse an audit 
trail 108. « the attacker were to render the audrt trail 108 invalid, then all of the rented applications 1 04. 105. 106 would 
identifv the abuse and subsequently refuse rental. 
r00521 In o«Jer to pro^de security, the architecture requires a smart card 112 that performs asymmetric cryptography, 
in this present example, the smart card 112 executes digital signatures. The smart card 11 2 contains private keying 
material 501 and a counter 502 (see Figure 5). ^ . -r., ^^^^ r^rr^ 

40 [00531 When the customer obtains the smart cand 1 12. the smart card 112 is in a secure state. The smart card pro- 
vides exactly two services that access either the private keying material or the counter: SlgnAndlncrementO and Get- 
CounterO. described in pseudo program code hereinafter (note that the symbol // denotes a comment and ^ denotes 
the assignment operator): 
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Signature SignAndlncrement (HASH h) // h is a message digest 
BEGIN 

[1] Compute the message digest of h and the smart card's 

counter, i.e., h' <r hash (h, counter ) 

[2] Sign h' with the private keying material 

[3] Increment the smart card's counter by 1 

[4] return the digital signature computed in step [2] 

'5 END 



integer GetCoiinterO 

20 

BEGIN 

[1] return the current value of the smart card's counter 

END 

25 



[0054] Coreider the following example trace. Suppose that the smart card's counter has an initial value of 6 and that 
30 one executes the following cperations: 

(1) Signaturel <r- SignAndlncrement(hash(„m1 ")) 
(ii) Signature2 <- SignAndlncrement(hash(„m2")) 
{iii)int1 <- GetCourtterQ 

35 

[0055] The results of this example are: 

Signaturel gets the digital signature (using the smart card's private keying material) of hash(hash(„m1 ").6) 
• Signature2 gets the digital signature (using the smart card's private keying material) of hash(hash(„m2"),7) 
40 • int1 gets 8 

[0056] The audit trail 108 contains a list of records, where each record has four f idds: nonce, string, counter, and sig- 
nature. The data input into the signature is hash(hash(nonce. string) .counter). Figure 6 illustrates an example audit trail 
with four recoids. In the first record, the nonce has the value 96, the string is ,WP 15 minutes public key 

45 9828a8c12a5873654bac684517d3afe3*' (where 9828a8c12a5873654bac684517d3afe3 denotes the message digest 
of a real public key), the counter's value is 0, and the digital signature is of hash(hash(96,"WP 15 minutes public key 
9828a8c12a5873654bac684517d3afe3"),0). Here, the digital signature was provided using the smart card's private 
keying material which con^esponds to public keying material 9828a8c12a5873654bac684517d3afe3. This public keying 
material may be extracted from WP's keyf ile. 

50 [0057] The counter never rolls over from its highest value to zero. When the counter reaches its highest value, e.g., 
2"'^^-1 . the system stops. 

[0058] A rented application appends a record to the audit trail by executing the Write routine, where the Write routine 
is embedded within the rented applications. "This routine generates an audit record and then sends the audit record to 
the Rental Sender 107. The Rental Sender 107 writes the audit record into a non-volatile, stable image of the audit trail. 
55 e.g.. on one or more files. The Rental Server 107 synchronizes access to me smart card 112 and the audit trail. The 
Rerrtal Server 107 cannot execute in a manner that thwarts system security. i.e., the rented appiicatior^ do not trust the 
Rental Server 107. If the Rental Server 107 were to act incorrectly, then there could potentially be a denial of service 
because it may be the case tiiat the rented applications could not validate the audit trail. 
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[0059] The Write routine is provided below in pseudo program code: 

Boolean Write (String str) 
BEGIN 

[1] n ^ generate a new nonce 

[2] hi <- hash{ n,str) 

[3] s ^ SignAndlncrement (hi) 

// below, c is a local copy of value in the smart card 
[4] c ^ GetCounter ( ) 

// below, decrement by 1 has no affect on smart card 
[5] decrement c by 1 
[6] h2 <- hash(hl,c) 

[7] validate that s is the signature of h2 against the 
public key found in the keyfile (if the validation 
fails, then return failure immediately without 
executing any further steps; the keyfile will be 
described later in detail) . 

[8] create the audit trail r <n,str,c,s> 
[9] append r to the audit trail 

[10] return TRUE if all of the preceding steps succeed, 
otherwise return failure 

END 



45 [0060] The ValidateTrail routine is also embedded in the rented application and should be executed periodically and 
is provided below in pseudo program code (assume that the system started with an initial counter value of zero): 
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Boolean ValidateTr^il {) 
BEGIN 

[1] c <- GetCoxanter ( ) 

[2] Write {c) // use the Write routine above, exit if 
// failure 

[3] r ^ Last record in the audit trail // this is the 

record that we just wrote in step [2] 
[4] Validate the signature stored in r against the 

public key stored in the keyfile 
[5] Validate that c is the same as the counter stored 

in r 

[6] FOR i^O UNTIL there are no more records, 
INCREMENT i by 1 
. th 

[6.1] r ^ i record from the audit trail 

[6.2] Validate the signature stored in r against 
the public key stored in the keyfile 
//Signature validation comprises the message 
// digest recomputation 



[6.3] Validate that i is the same as the coxinter 
stored in r 

[7] END FOR LOOP 

[8] if all of the above steps succeed, then return TRUE, 
otherwise r^eturn FALSE 
END 

50 

[0061 ] In steps [4] and [6.2], all of the input for the validation is from the audit record itself. By carefully analyzing all 
of the steps in the Write and ValidateTrail routines, it is clear that any attack that thwarts the intended use of these rou- 
tines causes failure. In this case, the rented applications notice the failure and do not permit themselves to be rented. 
55 [0062] The mechanism for recovering from a failure depends upon the vendor for each partiojlar rented application. 
The vendor may. for example, issue a new keyfile upon some customers* requests. Perhaps, the most significant ssue 
is recovery from accidental loss of the audit trail that may occur due to a disk enror. In order to protect against this situ- 
ation, the Rental Server 107 should be responsible for writing all records to the audit trail on behalf of all rented appli- 
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cations The Renlal Server should maintain a primary audit trail on the local fixed disk and at least one backup audrt 
S on a siarate medium e.g.. a floppy or a network file sender. One may for example, prov.de a service that permte 
She Sntil^^er toV-mTii au'dk trailsTo a secured network backup service. In this case, one can ensure prn,acy by 
permitting the rental server to encrypt the audit trail before transmission. 

Software Components (see Figure 2) 

[00631 We use the term challenge means to denote the portion of a rented P^oaram that inplements.compon^ 
tSenton The challenge means includes the implementation of the Write and ValidateTrail routines^ In additon fte 
chi rngrmeans instructs the remainder of the program concerning how to operate depending upon the resulte of me 
Wrt an^ VaHdateTrail routines. In addition, the challenge means interacts with the program's keyfile as descnbed 
below. 

Keyfile 404 

[0064] The creation of the keyfile 404 is performed by a keyfile generator, which is a program that executes at the 
vendor's facility. The vendor 401 must take care to guard this program. 
[0065] In use of the keyfile generator, an operator enters the following information: 

Vendor name: Vendor name is the name of the vendor's company 

Vendor password: Vendor password is the password that unlocks the vendor company's private keying material. 
Company employees who do not know the password cannot generate keyf iles. 

Customer name: TTie customer name is the distinguished name of a customer (defined in [2]) for whom to generate 
a keyfile. The name indexes into a database of public keying material. 

Keyfile name: The keyfile name is the name of a new keyfile. 

[0066] After obtaining this information, the keyfile generator builds the keyf fle 404. containing a ^."^^^^^^^^^^ 
SJng (CIS) described later Portions of the keyfile 404 appear to the customer 402 as a completely random sequence 
of values. 

r00671 Building of the keyfile 404 involves the followtfing operations. • , • «.„ air.nn 

S First. tSe keyfile generator creates a file and inserts the customer's public '<«y'"?^^at^^'i;^°i^^^^ 
Lth thousands of decoy brts. In the present example, each keyf ile 404 contains approximately ^80 000 decoy brts. This 
Tii^er of bits represents a significant amount of decoy material, yet can fit into a standard e-mail message. 
?0^] Each Sile 404 stores the CIS in a different location. Additionally, each keyfile 404 has n^^" 
SSLon embSded in it without disclosing the required encryption key This encrypted customer '"^1"^°" P^""^ 
L veS to easily identify the owner of a keyffle 404 in the event that the keyfile 404 appears in ^ P^'^'c Ic^'O" 
as a bul^n boaJl. The keyfile generator then encrypts and r^encrypts the keyfile (or portions of ^^J^^^^'^'^- 
tiple tiLs. using different Algorithms. FinaHy, the keyfile generator signs the keyfile 404 using the vendor s private key- 

K'tSi^rs's^t^t.^^^^^^^^ 

Ihe vendor's signature using the pubDc keying material stored in the challenge means' binary and access the decrypted 

" Afler'h'iJX'et^ the keyfile 404. the vendor's computer sends the keyfile 404 to the customer 402 by elec- 

JSSrIhe CIS is a string that contains the customer's public keying material, the customer's ^^J'^^'!;^^^ 
Z'l rental threshold, "^e access rights Prov^^ i*-ation to s.^.^^^^^^^ 



30 



35 



40 



SO 



resVirnZ^i^a^^^^^^^^^ 

tiSfpermrt the ^cation to send audio infbmiation to the customer's speakers. Presumab y. highly tmsted custom- 
ei or^omeiSSho pay more money obtain better access rights in their keyfiles. TT.e keyfDe 404 rr«y have muftpte 
uSs eTauthorizationfor the application and rental information. In the following, the operaton of the ^1 mecha- 
nsmisdes^J^S^fnmoredetail.™^ 
55 [00731 When the challenge mechanism 202 starts the process, the challenge niechanism 202 (see We 7) 
aSes the keyf fle 404 assciiated with the rented application and calls a signature validaton funcbon 203 in the chal- 
SS^^anS 202 to validate the vendor's signature of the keyf He 404. using the vendor's ^^^'^^^^^^^^^'^^ 
Sfs embedded in the challenge mechanism 202. This validation of the keyfile signature ensures that an attacker can- 
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not modify the keyf ae 404 or its digital signature without additionally modifying the challenge mechanism 202. The ven- 
dor 401 may optionally augment this protection using additional proprietary lines of defense. If the keyfile 404 has been 
modified, the challenge mechanism 202 hangs the rented program, or otherwise disturbs normal program execution. 
[0074] Assuming the Signature of the keyfile 404 is validated, the challenge mechanism 202 then parses the keyfile 
5 404. using a proprietary, vendor-specific algorithm, to locate the customer's public keying material in the keyfile 404, 
and extracts the customef s putdc keying material. 

[0075] Subsequently wnenever required by the software rental mechanism, the challenge mechanism (challenge 
means) executes the software rental protocol as described earlier. That is, the challenge means securely appends audit 
records to the audit trail as described earlier. 

10 

Nonce generator 

[0076] Generation o* a ncnce is performed by a nonce generator included in the challenge mechanism 202. Operation 
of the nonce generator is as Wtows (see figure 3). 
15 [0077] First, the norice genetatof queries a large number of system parameters, e.g. the system time, the amount of 
space remaining free m tt>e page tatrfe. the number of logical disk drives, the names of the files in the operating system's 
directory, etc. 

[0078] Next, the nonce genefator builds a random number, using a random number generator. The random number 
generator consists of two process threads, referred to herein as Thread 1 and Thread 2. Figure 5 shows the operation 
20 of Thread 1 , which is the mam thread of the random number generator. 

[0079] (Box 301) Thread 1 first creates a data structure va)ue_list, for holding a list of counter values. The list is initially 
empty. 

[0080] (Box 302) Thread i sets a current counter value to zero, and sets a done_test flag to FALSE. 
[0081] (Box 303) Thread 1 then forks Thread 2. Thread 2 posts an asynchronous dsk access, and then sleeps until 
25 the disk access is conrplete When the disk access is complete. Thread 2 sets the done_test flag to TRUE. Note that 
Thread 1 and Thread 2 share the done_test flag. 
[0082] (Box 304) Thread 1 increments the counter value by one. 

[0083] (Box 305) Thread 1 then tests whether the done_test flag is now TRUE, indicating that the disk access initiated 
by Thread 2 is complete. If done_test flag is FALSE, the thread returns to box 54. Thus it can be seen that, while waiting 
30 for the disk access to complete. Thread 1 continually increments the counter value. 

[0084] (Box 306) When donejest flag is TRUE, Thread 1 terminates Thread 2, and saves the counter value in the 
first free location in value_fist. 

[0085] (Box 307) Thread 1 then calls a Statstest function, which estimates the degree of randomness of the counter 
values (or portions of counter values, e.g.. low-order bits) saved in valuejist. This function may use the Chi-Square 

35 Test, the Kolmogorov-Smimo/ Test, or the Serial Correlation Test, which are described in [5]. The Statstest function 
may be optimized to ensure tf^t complicated calculations are not repeated for each disk access. The Statstest function 
returns a value which indicates how many low-order bits of each saved counter value should be considered random. 
[0086] (Box 308) Thread 1 corrpares the value returned by the Statstest function when combined with the length of 
the valuejist with a predetermined threshold value, to determine whether enough random bits have now been gener- 

40 ated. If not enough random brts have been generated, the process returns to tx)x 302 atx)ve, so as to generate and save 
another counter value. 

[0087] (Box 309) When the required number of random bits has been generated. Thread 1 extracts the specified 
number of low-order bits from each counter value in the value_list, and returns this sequence of bits as the output ran- 
dom number. 

45 [0088] In summary, it can be seen that the random number generator exploits the unpredictability in the timing of a 
series of disk accesses as a source of rarKlomness in the generation of nonces (see [4]). By forking new threads on 
each disk access, the random number generator also exploits unpredictabilities in the operation of the operating sys- 
tem's scheduler as a second source of randomness. 

[0089] The analysis performed by the Statstest function permits the random number generator to self-tune for any 
so speed processor and disk, by computing the number of low-order bits of each saved courrter value to return. For exam- 
ple, a system with a high-variance disk access time will generate more random bits per<lisk access than a system with 
a low-variance disk access time. For example, for a Quantum 1 080s disk (6ms average write time), and a 486 66 Mhz 
processor, the system generates approximately 45 bits per second. Alternatively, one may hard code the number of bits 
per-disk access and use a de-skewing technique to ensure a good degree of randomness. 
55 [0090] The nonce generator also queries the operating system to ensure that it posts each disk access to an actual 
disk. The final output nonce is formed by combining the output random number from the random number generator with 
the result of querying the system parameters as described above using a message digest 

[0091 ] The nonce generator described above works best when executing on an operating system that provides direct 
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acce. «. *e .... ^ « 0, V*d»» NT « 

mechanism ard «rte direoly 10 SS^* fc^wS^ & and W«l»«5 NT, a program ma, only 

r,^ur4Lrrr?'oSJreird:;^»is^^^^^^ 

;o*S7»m,opem.„gsy=,^does«^ed^ec,a=.a^».r»*K;^^^^^ 

irrs'i^-^sXo^^re^-^^^^^^ 

disk access time. ^ ^ operating system permits a program to fork 

[0093] -me example of the invenbon described above ^^^'"f Jl™^!^'^^ ^ a^umes that the operating 

Litiple threads within a single address space. ^J*;°"^5^,^3\JS'2':^^^^ modern operating systems 

ra-:iTor"s-s^^^^^ 

querying a physical dock. 
Rnme Possi '->'*^ Mndifications 

[0094, .n order to improve per^rmance. one -V au^^ ^^^^^^^^ 

Here, the trusted service periodically valKlat^ ^^^^^ J^^o^^Ttto^^^^^ ^i^tor reco«J may contain is a digital 
that securey vouches for the previous ^^^I'^^'^^^S^^S^^^^^^^^^ signature uses the private key of the audit 
signature of the hash of all preceding audrt ecords .n ^^Jir signatures of records that precede the val- 

vaUon service). Henc^fortK^^^^^^ 

idator record. Tnea--.* • — " 

e-mail connection. ^ ra ^r.ri \Pi it is nossble that the counter value of tlie initial record is 

SoK:i^TSL«^ra.'SL^'s.:5S^S,Mn^«-o*--acco„.«*ee^ 

smart card manufacturer and/or personalizer. ^ ^ r. .<^tnmer obtains a smart caid. In this case, the ven- 

ing payment). 

Universal Private Keying Material 

10098] lnavariamtotheexamp.emechanism.ai>custome.r^^^^^^^ 
Lre. the vendor tn^sts that me smart ca^ J^er^e^^^^ 

rial outside of the smart card. As in the case of Figure 5. the rt caixte have the same 

a counter 502. Additionally, the smart card contains ^ JJ^.^^^^,^^^^^ from the one described 

serial number. Step [1] of the SignAndlncrement routne implemented on the smart caro 
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above as follows: 

[1] compute the message digest of h and the serial number and the smart card's counter, i.e.. 

h* 4r- hash(h,seriaLnumber,counter) 
l<»«, in add-on » S,sn.n<«no,».a« and «» G«C„n», mu.na.. *o »na« »d ^ «» 

GetSerialNumber routine: 



55 



12 



OCID- <EP 0S9514aA1J_> 



EP 0 895 148 A1 



string GetSerialNumber ( ) 

BEGIN 

[1] return the smart card's serial number 

END 



[0100] The customer additionally serds his or her smart card's serial number The keyfile 404 contains the following 
information: 

75 • The universal public keying material potentially shared by all customers 
The unique serial number of the customer's smart card 

The hash records stored in the log file, take into account the serial number. For example, the first hash record of Figure 
6 has the following information for a message signature: 
20 Signature of hash(hash(96,WR..).seriaLnumber,0) 

[0101] The Write routine step [6] has the following modification: 
[6] h2 <r- hash(h1,serlaLnumber.c) 

[0102] The VaJidateTrail routine's steps [4] and [6,2] must use the serial number (otherwise they would always fail). 
We do not specify the vehicle that the Write and VaiidateTraH routines use to obtain the serial number of the local smart 
25 card. One could, for example, query the smart card a single time and then store the serial number in a file in the local 
file system. 

[0103] A software vendor could p)otentially provide a rented application with a complex threshold calculation. For 
example, the vendor may rent blocks of 1000 units. For each hour that the software executes between 20.00 (8:00 PM) 
and 6.00 (6:00 AM) the next morning, the log record defines one unit; and for each hour in a different portion of the day. 
30 the log record defines two units. So, for example, a customer could potentially use the sofhware for 1000 nighttime 
hours, 500 daytime hours, or some calculated combination of nighttime and daytime hours. 

[0104] Alternatively a threshold may be calculated using a tx>oiean connbination of multiple parameters. A software 
vendor could potentially provide a rental application with no thr^hokJ. Every month, the software vendor obtains tiie 
cun-ent value of the SUSL and gets the audit trail. The vendor then validates the audit trail and charges a fee accord- 

35 ingly If the customer does not wish to continue renting the software, then the vendor asks to have the smart card 
returned. It is very easy to query the value of the SUSL if the customer briefly returns tiie smart card to the vendor. Oth- 
erwise, tiie vendor accesses the smart card via a network interface. First, the vendor generates a random nonce and 
asks the customer to use Write(nonce) to append the nonce to the audit trail. Next, the vendor executes tiie 
ValidateTrail routine remotely. This service requires the customer (or programs that operate on the customer's behalf) 

40 to relay ttie vendor's requests from the network to the smart card. The vendor then checks the validated audit trail for 
the nonce. 

Software Copy Protection 

45 [0105] The software rental mechanism may be augmented with an additional software copy protection mechanism. 
The software copy protection mechanism ensures that only the autiiorized customer may rent the program. The soft- 
ware copy protection mechanism may potentially share a keyfile with the software rental mechanism. 

Protected Content 

50 

[01 06] Any of the rental mechanisms described in this document may also be used for renting documents as opposed 
to software. The approach Is to rent a Viewer program which uses a file. 
[0107] The following publications are cited in this document: 

55 [1] Hardlock API. Manual Implementation of Harlock Software Protection Systems. High-Level API Version 3 Appli- 
cation Programming Interface. FAST Software Security-Group. FAST Document: High-Level API. Revision: 4.00e, 
Status March 1. 1996 
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[2] A. Menezes et al. Handbook of Applied Cryptography. CRC Press. Inc. ISBN 0-8493-8523-7. S. 22 - 23, 224 - 
233. 250 - 259. 308 - 31 1 . 405 - 424. 433 - 438. 572 - 577. 1997 

[3] R. Rivest. The MD5 message<Jigest algorithm, RFC 1321. April 1992. 

[4] R Fenstermacher et al. Cryptographic randomness from air turbulence in disk drives. Advances in Cryptology: 
Crypto '94. pp. 114 - 120. Springer Verlag. 1994 

[51 D Knuth. The Art of Computer Programming. Vol. 2. Seminumerical Algorithms. Addison-Wesley Publishing 
Co.. Reading MA, 2nd Edrtion. 1981. pp. 38-73. ISBN 0-201-03822-6. 
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Claims 

1. A software rental system corrprising at least one rented program permitting at least one service to a customer with 
75 a customer's response n>eans. wherein 

- said rented program has no access to a customer's private keying material. 

- using asymmetric cryptography, said customer's response means proves to the rented program, that said cus- 
tomer's response mear^ has access to the customer's private keying matenai. and 

- said rented program does r>ot permit said at least one service to said customer unless the proof is successful. 

A software rental system comprising at least one rented program and private keying material such that the software 
rental system securely stores audit trails, wherein the con-ectness of said audit trails is validated using asymmetric 
cryptography. 

A GCfhvare rental system accord-ng to claim 2 wherein the at least one re-nted nrr^gram has no access to the private 
keying material. 

4. A software rental system according to claim 2 or 3 wherein the audit trails are comprising the extent to which the 
30 rented program has been remed. 

5. A software rental system according to claim 1 wherein validation ensures all of the following: 

no audit trail has been modified. 
35 - no audit trail has been deleted, and 
the list of all audit trails is up to date. 

6. A software rent^ system in accordance to one of the claims 2 to 5 in which the rented program fails to execute or 
executes in a linnited nxxle it said validation fails. 

7. A software rental system in accordance to daim 0.5 In which the system may rent more programs than available 
Secure Updatable Storage Locations. 

8. A software rental system in accordance with claim 7 in which only a single Secure Updateable Storage Location is 
45 required in order to rent multple programs. 

9 A software rental system in accordance with daim 8 in which a first part of the audit trail is stored on a ^on-secured 
media and a second part of the audit trail is stored in a secure updateable storage location, wherein the first part 
of the audit trail comprises an amount of stored audit trails. 
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10 A software rental method using a software rental system in accordance with daim 9 in which a customer obtains 
' and uses a secure updateable storage location for renting software and subsequently obtains new rentai software 
without requiring a new secure updateable storage location or resetting an existing secure updateable storage 



location value. 



11 A software rental method in accordance with daim 10 in whidi multiple rented programs are using the same rental 
■ mechanism despite the fact that the rented progrants were created without knowing common private keying mate- 
rial. 
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1 2. A software rental system according to claim 1 with multiple rented programs. 

13. A software rental system according to claim 12, wherein 

5 - said rented programs have the same keying material, and 

customer's private keying material of said keying material is stored on a smart card. 

14. A software rental system according to one of the claims 1 to 1 1. wherein a customer's private keying material is 
stored on a smart card. 

10 

1 5. A software rental system according to one of the daims 1 to 1 4. wherein 

at least one usage parameter of said at least one program is stored in an audit trail, and 
said rented program does not permit said at least one service to said customer unless said at least one usage 
75 parameter is within a predetermined threshold. 

16. A software rental system according to claim 15, 

wherein at least two usage parameters of said at least one program are stored in said audit trail. 

20 1 7. A software rental system according to claim 15 or 16, 

wherein satd at least one usage parameter is a rental time period for renting said at least one program. 

18. A software rental system according to one of the claims 15 to 17, 

wherein said at least one usage parameter is an amount of usages of said at least one program. 

25 

19. A software rental system according to one of the daims 15 to 18. wherein 

sad at least one usage parameter is checked multiple times, and 

sad rented program does not permit saki at least one service to said customer unless said at least one usage 
30 parameter is in a predetermined interval each time it is checked. 

20. A software rental system according to one of the daims 1 to 19, 

with a rental server that synchronizes access to a smart card on which a customer's private keying material is 
stored and/or to an audit trail in which usage parameters of said at least one program is stored. 

35 

21 . A software rental system according to one of the daims 1 5 to 20, wherein 
sad program stores said at least one usage parameter in said audit trail. 

22. A software rental system according to claim 21 , wherein 
40 sad audit trail is stored securely 

23. A software rental system according to one of the daims 13 to 22. wherein 

the smart card performs an atomic routine that both executes a digital signature and an operation computed over 
a storage location that changes over time. 

45 

24. A software rental system according to one of the daims 1 to 23, wherein 
the program is a viewer program which uses a file. 

25. A software rental system according to one of the daims 1 to 24, 

50 wherein the system indudes a keyfile for holding public keying material. 

26. A software rental system according to claim 25. 

wherein said public keying material held in said keyfile is cryptographically secured, whereby it is computationally 
infeasible to alter any portion of the keyfile. induding said public keying material, without altering the challenge 
55 means. 

27. A software rental system according to claim 26. 

wherein said keyfile includes information identifying said customer said program has been supplied. 
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28. A software rental system according to claim 27, 
wherein said keyfile includes decoy bits for disguising the said public keying material held therein. 

29. A software rental system according to one of the claims 1 to 28, wherein the program is copy protected. 

30. A method of distributing a program to a plurality of customers wherein each customer has a software rental system 
according to claim 1 or 2, and wherein every customer receives an identical copy of said program. 

31. A method for renting software comprising at least one rented program permitting at least one service to a customer 
with a customer's reponse means, wherein 

said rented program has no access to a customer's private keying material, 

- using asymmetric cryptography, said customer's reponse means proves to the rented program, that said cus- 
tomer's reponse means has access to the customer's private keying material, and 

- said rented program does not permit said at least one service to said customer unless the proof is successful. 

32. A method for renting software comprising at least one rented program and private keying material such that the 
software rental system securely stores audit trails, wherein the correctness of said audit trails is validated using 
asymmetric cryptography. 

33. A method according to claim 32 wherein said at least one rented program has no access to the private keying mate- 
rial. 

34. A method according to claim 32 or 33 wherein the audit trails are comprising the extent to which the rented program 
25 has been rented. 

35. A method according to claim 32 wherein validation ensures all of the following: 

no audit trail has been modified, 
30 - no audit trail has been deleted, and 
the list of all audit trails is up to date. 

36. A method in accordance to one of the claims 31 to 35 in which the rented program fails to execute or executes in a 
limited mode if said vafidation fails. 

37. A method in accordance one of the claims 31 to 36 in which the system may rent more programs than available 
Secure Updatabie Storage Locations. 

38. A method in accordance with claim 37 in which only a single Secure Updateable Storage Location is required in 
40 order to rent multiple programs. 

39. A method in accordance with claim 38 in which a first part of the audit trail is stored on a non-secured media and 
a second part of the audit trail is stored in a secure updateable storage location, wherein the first part of the audit 
trail conrprises an amount of stored audit trails. 

40. A software rental method using a software rental system in accordance with claim 39 in which a customer obtains 
and uses a secure updateable storage location for renting software and siA)sequently obtains new rented software 
without requiring a new secure updateable storage location or resetting an existing secure updateable storage 
location value. 
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41. A method according to one of the claims 31 to 40 with multiple rented programs. 

42. A method according to daim 41 , wherein 

55 - said rented programs have the same keying material, and 

- customer's private keying material of said keying material is stored on a smart card. 

43. A method according to daim 42, wherein a customers private keying material is stored on a smart card. 
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44. A method according to one of the claims 31 to 43, wherein 

at least one usage parameter of said at least one program is stored in an audit trail, and 
said rented program does not permit said at least one service to said customer unless said at least one usage 
5 parameter is within a predetermined threshold. 

45. A method according to claim 44, 

wherein at least two usage parameters of said at least one program are stored in said audit trail. 

10 46. A method according to claim 44 or 45, 

wherein said at least one usage parameter is a rental time period for renting said at least one program, 

47. A method according to one of the claims 31 to 46, 

wherein said at least one usage parameter is an amount of usages of said at least one program. 

75 

48. A method according to one of the claims 31 to 47, wherein 

said at least one usage parameter is checked multiple times, and 

said rented program does not permit said at least one service to said customer unless said at least one usage 
20 parameter is in a predetermined interval each time it is checked. 

49. A method according to one of the claims 31 to 48, 

with a rental server that synchronizes access to a smart card on which a customer's private keying material is 
stored and/or to an audit trail in which usage parameters of said at least one program is stored. 

25 

50. A method according to one of the claims 31 to 49, wherein said program stores said at least one usage parameter 
in said audit trail. 

51. A method according to claim 50, wherein said audit trail is stored securely. 

. 30 

52. A method according to one of the claims 31 to 51 , wherein the smart card performs an atomic routine that both exe- 
cutes a digital signature and an operation computed over a storage location that changes over time. 

53. A method according to one of the claims 31 to 52. wherein the program is a viewer program which uses a file. 

35 

54. A method according to one of the claims 31 to 53, 

wherein the system includes a keyfiie for holding public keying material. 

55. A method according to claim 54. 

40 wherein said public keying material held in said keyfiie is cryptographically secured, whereby it is computationally 
infeasible to alter any potion of the keyfiie, including the public keying material, without altering the challenge 
means. 

56. A method according to daim 55» 

45 wherein said keyfiie includes information identifying said customer said program has been supplied. 

57. A method according to daim 56, 

wherein said keyfiie includes decoy bits for disguising the said public keying material held therein. 

so 58. A method according to one of the claims 31 to 57. wherein the program is copy protected. 
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